Skip to content

configs: remove duplicate INI keys (first occurrence wins)#4092

Open
PeterStolz wants to merge 3 commits into
LinuxCNC:masterfrom
PeterStolz:fix-conflicting-duplicate-ini-keys
Open

configs: remove duplicate INI keys (first occurrence wins)#4092
PeterStolz wants to merge 3 commits into
LinuxCNC:masterfrom
PeterStolz:fix-conflicting-duplicate-ini-keys

Conversation

@PeterStolz
Copy link
Copy Markdown

What

Several shipped sim/demo configs define the same INI key more than once within one section. LinuxCNC only reads the first occurrence, so the later lines are silently ignored — in two cases hiding the author's intent. Split into two commits:

  1. conflicting duplicates (different values — a value was silently dead)
  2. redundant duplicates (same value — pure no-op de-clutter)

How I found it

I'm building a LinuxCNC VS Code extension (HAL/INI/G-code language support) — https://marketplace.visualstudio.com/items?itemName=PeterStolz.linuxcnc-lsp — and its INI linter flagged duplicate keys across a number of in-tree configs, so I went through each to confirm they're real.

Why the second value is ignored

IniFile::findTag(tag, section, num) defaults to num=1 and returns the first match in file order (src/emc/ini/inifile.cc); there is no concatenation for scalar keys. The same is true of the inivar CLI used by scripts/linuxcnc and of linuxcnc.ini(...).find() used by the GUIs. Confirmed on a 2.10 run-in-place build:

$ inivar -ini configs/sim/axis/histogram_demo.ini -var MAX_LINEAR_VELOCITY -sec TRAJ
1.2          # first wins; the file's later 1.2345 is ignored

>>> linuxcnc.ini(".../woodpecker_xyzab.ini").find("DISPLAY","GEOMETRY")
'XYZABCUVW'  # findall() -> ['XYZABCUVW','xyzab']; the intended 'xyzab' was dead

Commit 1 — conflicting duplicates

Behaviour-changing (restore intent):

  • sim/axis/gladevcp/probe.ini[RS274NGC] SUBROUTINE_PATH was set twice, so the second value (../../nc_files/gladevcp_lib, the gladevcp demo's O-word subs, per its own comment) was never on the path. Merged into one colon-separated SUBROUTINE_PATH.
  • sim/woodpecker/woodpecker_xyzab.ini[DISPLAY] GEOMETRY = xyzab (added for this XYZAB variant) was overridden by a leftover XYZABCUVW; made xyzab effective.

No-op (the removed value was already the ignored one):

  • woodpecker_xyzab.ini — duplicate [RS274NGC] PARAMETER_FILE (metric_parameters.txt dead; keeps woodpecker.var).
  • woodpecker_xyza.ini — a pasted-twice [DISPLAY] spindle-override block.
  • histogram_demo.ini, ini_hal_demo.ini — stray second [TRAJ] MAX_LINEAR_VELOCITY = 1.2345.
  • sim/axis/vismach/5axis/bridgemill/5axis.ini — redundant [TRAJ] MAX_ANGULAR_VELOCITY = 360 (identical to 360.0).

Commit 2 — redundant (same-value) duplicates

Pure de-clutter, no behaviour change:

  • [TRAJ] MAX_LINEAR_VELOCITY = 58 in sim/axis/gantry/gantry.ini, gantry_jjog.ini, sim/qtaxis/gantry/qt_gantry.ini, sim/qtvcp_screens/qt_gantry.ini, qtdefault_gantry.ini.
  • [RS274NGC] HAL_PIN_VARS = 1 in sim/axis/vismach/scara/scara.ini, sim/qtaxis/non-trivial/scara/scara.ini, sim/qtvcp_screens/non-trivial/scara/scara.ini.
  • [DISPLAY] GEOMETRY = XYZCBW in sim/axis/vismach/5axis/bridgemill/5axis.ini.

Not included

The Sherline Sherline4Axis_{inch,mm}.ini configs have a # for gui only block where the first [TRAJ] MAX_LINEAR_VELOCITY (25) wins over a more realistic second value (.36 in/s · 8 mm/s). Fixing that changes the effective max velocity — a judgement call — so it's left for separate discussion.

LinuxCNC's INI reader returns the first occurrence of a key within a
section (IniFile::findTag with num=1), so a second line with the same key
in the same section is silently ignored. Several shipped sim/demo configs
contain such duplicates where the later value is dead -- in a couple of
cases masking the author's evident intent. The first-wins behaviour was
confirmed on 2.10 with `inivar` and the linuxcnc.ini Python reader.

- sim/axis/gladevcp/probe.ini: [RS274NGC] SUBROUTINE_PATH was set twice, so
  the second value (../../nc_files/gladevcp_lib -- the gladevcp demo's
  O-word subs) was ignored and those subs were unreachable. Merge both into
  one colon-separated SUBROUTINE_PATH.
- sim/woodpecker/woodpecker_xyzab.ini: [DISPLAY] GEOMETRY = xyzab (added for
  this 5-axis variant) was overridden by a leftover XYZABCUVW; make xyzab
  effective. Also drop a duplicate [RS274NGC] PARAMETER_FILE.
- sim/woodpecker/woodpecker_xyza.ini: drop a pasted-twice spindle-override
  block ([DISPLAY] MIN/MAX_SPINDLE_0_OVERRIDE).
- sim/axis/histogram_demo.ini, ini_hal_demo.ini: drop a stray second
  [TRAJ] MAX_LINEAR_VELOCITY (1.2345) after 1.2.
- sim/axis/vismach/5axis/bridgemill/5axis.ini: drop a redundant
  [TRAJ] MAX_ANGULAR_VELOCITY (360, identical to 360.0).
Follow-up to the previous commit. These configs repeat a key within one
section with the *same* value. LinuxCNC uses the first occurrence, so the
repeats are pure redundancy with no behaviour change -- removing them just
de-clutters the configs.

- [TRAJ] MAX_LINEAR_VELOCITY = 58 duplicated in:
  sim/axis/gantry/gantry.ini, sim/axis/gantry/gantry_jjog.ini,
  sim/qtaxis/gantry/qt_gantry.ini, sim/qtvcp_screens/qt_gantry.ini,
  sim/qtvcp_screens/qtdefault_gantry.ini
- [RS274NGC] HAL_PIN_VARS = 1 duplicated in:
  sim/axis/vismach/scara/scara.ini,
  sim/qtaxis/non-trivial/scara/scara.ini,
  sim/qtvcp_screens/non-trivial/scara/scara.ini
- [DISPLAY] GEOMETRY = XYZCBW duplicated in:
  sim/axis/vismach/5axis/bridgemill/5axis.ini

The Sherline4Axis configs also have same-value duplicates, but they sit in
a "# for gui only" block next to a conflicting MAX_LINEAR_VELOCITY that needs
a separate decision, so they are left for a follow-up.
Comment thread configs/sim/woodpecker/woodpecker_xyzab.ini Outdated
GEOMETRY is uppercased at parse time (axis.py, gremlin), so this is a
cosmetic change to match the uppercase convention used across the INI
files and this config's own COORDINATES = XYZAB.

Addresses review feedback on PR LinuxCNC#4092.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants